1. Field of the Invention
The present invention relates generally to an improved data processing system, and more particular, to a computer implemented method, data processing system, and computer program product for a secure bytecode instrumentation facility.
2. Description of the Related Art
Bytecode instrumentation is becoming a common way to extend the functionality of Java™ and Microsoft™ .Net applications when, for any reason, access to the application source code is not available. With bytecode instrumentation, it is possible to add functionality like tracing, logging, performance, license usage stubs, etc., even when the application has already been deployed in the customer environment.
Bytecode instrumentation facilities can be placed in two categories: facilities that modify the application binaries, and facilities that modify the application code segments leaving the file system binaries intact. With regard to security issues of facilities in the second category, different tools exist today that automatically instrument Java™ applications by injecting code fragments into the application classes while the classes are loaded into memory by the Java™ Virtual Machine (JVM™) Bytecode Engineering Library™ (BCEL), Java™ Runtime Analysis Toolkit (JRat), JBoss™, Aspect Oriented Programming™ (AOP), etc. (from the open source community), Just-in-Time Instrumentation (JITI), .Net Instrumentation (NETI) (from International Business Machines Corporation), as well as others from companies that sell system management software for managing Java™ and .Net applications. When used with good intentions, this bytecode instrumentation technology is very helpful to provide immediate fixes to customers, to extend applications with the necessary code so that a managing tool can manage them, and to allow a support team to perform application customizations for special customer needs that cannot be satisfied by the company supplying the application.
Unfortunately, when in wrong hands, this technology enables hackers to insert malicious code to steal confidential data or crash applications while a customer has very little awareness of what is going on. The customer may not be aware of the problem since typical investigation methods, such as checking that all application binaries are intact or running an antivirus tool, would not reveal any problem as the malicious modifications are done in memory, not in the file system. Thus, the strength of this bytecode technology—its ability of modifying applications by only touching the code segments—is also his Achilles' heel. Without powerful security measures, its advantages are obliterated by the danger that malicious users can take control of the bytecode instrumentation.
Existing bytecode instrumentation facilities do not provide strong security measures to prevent hackers from exploiting the facilities. The only security measure provided requires the instrumentation facility to be installed in such a way that only an administrator can access the code fragments (usually Java™ class files and Jar files) that are injected into the target application, and the registry (usually a file or a database) that specifies which code fragments go in which locations of the application. However, a problem with this simple security mechanism is that if a hacker finds access to the administrator password of a system, the hacker can replace code fragments or inject new code fragments modifying customer applications in a way that it is very difficult for the customer to detect.